Today's Internet-driven economy has accelerated users' expectations for unfettered access to information resources and transparent data exchange among applications. One of the key issues limiting data interoperability today is that of incompatible metadata. Metadata is information about other data, or simply data about data. Metadata is typically used by tools, databases, applications and other information processes to define the structure and meaning of data objects.
Unfortunately, most applications are designed with proprietary schemes for modeling metadata. Applications that define data using different semantics, structures and syntax are difficult to integrate, impeding the free flow of information access across application boundaries. This lack of metadata interoperability hampers the development and efficient deployment of numerous business solutions. These solutions include data warehousing, business intelligence, business-to-business exchanges, enterprise information portals and software development.
An improvement is made possible by establishing standards based upon XML Document Type Definitions (DTDs). However, DTDs lack the capability to represent complex, semantically rich, hierarchical metadata.
A further improvement is made possible by the Meta Object Facility (MOF) specification. MOF is described in a text entitled “Meta Object Facility (MOF) Specification”, Object Management Group, Inc., version 1.3, March 2000. The MOF specification defines a standard for metadata management. The goal of MOF is to provide a framework and services to enable model and metadata driven systems. The MOF is a layered metadata architecture consisting of a single meta-metamodel (M3), metamodels (M2) and models (M1) of information. Each meta level is an abstraction of the meta level below it. These levels of abstraction are relative, and provide a visual reference of MOF based frameworks. Metamodeling is typically described using a four-layer architecture. These layers represent different levels of data and metadata. Layers M1, M2 and M3 are depicted in FIG. 1A. FIG. 1B includes a summary and example of each layer.
The information layer (also known as the M0 or data layer) refers to actual instances of information. These are not shown in FIG. 1A, but examples of this layer include instances of a particular database, application data objects, etc.
The model layer 100 (also known as the M1 or metadata layer) defines the information layer. The model layer 100 describes the format and semantics of the data. The metadata specifies, for example, a table definition in a database schema that describes the format of the M0 level instances. A complete database schema combines many metadata definitions to construct a database model. The M1 layer 100 represents instances (or realizations) of one or more metamodels.
The metamodel layer 105 (also known as the M2 or meta-metadata layer) defines the model layer. The metamodel layer 105 describes the structure and semantics of the metadata. The metamodel specifies, for example, a database system table that describes the format of a table definition. A metamodel can also be thought of as a modeling language for describing different kinds of data. The M2 layer represents abstractions of software systems modeled using the MOF Model. Typically, metamodels describe technologies such as relational databases, vertical domains, etc.
The meta-metamodel (M3) layer 110 defines the metamodel layer. The meta-metamodel layer 110 describes the structure and semantics of the meta-metadata. It is the common “language” that describes all other models of information. Typically, the meta-metamodel is defined by the system that supports the metamodeling environment. In the case of relational databases, the meta-metamodel is hard-wired by the SQL standard.
In addition to the information-modeling infrastructure, the MOF specification defines an Interface Definition Language (IDL) mapping for manipulating metadata. More specifically, for any given MOF compliant metamodel, the IDL mapping generates a set of Application Program Interfaces (APIs) that provide a common IDL programming model for manipulating the information contained in any instance of that metamodel. The MOF model itself is a MOF compliant model. Therefore, the MOF model can be described using the MOF. Consequently, APIs used to manipulate instances of the MOF Model (i.e., metamodels) conform to the MOF to IDL mapping.
Other mappings may be used to manipulate metadata. The mappings define how to generate a set of APIs that provide a common programming model for manipulating metadata of any MOF compliant model. Using the mappings, applications and tools that specify their interfaces to the models using MOF-compliant Unified Modeling Language (UML) can have the interfaces to the models automatically generated. Using this generated set of APIs, applications can access (create, delete, update and retrieve) information contained in a MOF compliant model. This is illustrated below with reference to FIG. 2.
A sample mapping for the Java™ language is as follows: A class proxy interface name <ClassName>Class and an instance interface named <ClassName> are generated for each class. For example, a class named “abc” has a class proxy interface named “abcClass” and an instance interface named “abc”. Two methods are generated for each attribute/reference pair in the corresponding instance interface. The first method sets the value of an attribute or reference and is named set<Attribute/ReferenceName>. The second method gets the value of an attribute or reference and is named get<Attribute/ReferenceName>. An operation method is also generated for each operation in the corresponding instance interface. The operation method name is the same as the operation name. Each class proxy interface includes a method named create<ClassName> to create a class instance. A package proxy interface named <PackageName>Package is also generated for each package. Each package proxy interface includes accessor methods named get<ClassName>Class for each class contained by the package. These methods are used to return the class proxy for the corresponding class. The above mapping is referred to herein as a Java™ Metadata Interface (JMI).
Turning now to FIG. 2, a flow diagram that illustrates using manually coded Java™ Metadata Interface (JMI) interfaces to access a metamodel is presented. At 200, a repository receives a metamodel. At 205, the repository automatically generates JMI interfaces for the metamodel. At 210, a repository user manually develops the software implementation for the JMI interfaces generated at reference numeral 205. At 215, the repository user compiles the coded JMI interface implementations. At 220, the repository user uses the compiled JMI interface implementations to access the metamodel.
Turning now to FIG. 3, a flow diagram that illustrates a method for automatically generating Java™ metadata interfaces is presented. FIG. 3 provides more detail for reference numeral 205 of FIG. 2. At 300, a package proxy interface is generated for each object of type “Package”. Sample package proxy interface 305 includes accessor methods 310, 315 for each class proxy in the package. Each accessor method name has a “get” prefix and a “Class” suffix. The package proxy interface name includes the package name followed by “Package”. At 320, a class proxy interface is generated for each object of type “Class”. Sample class proxy interface 325 includes factory methods 330, 335 for a class. Each factory method name has a “create” prefix. The class proxy interface name includes the class name followed by “Class”. At 340, an instance interface is generated for each object of type “Class”. Sample instance interface 345 includes “get” and “set” methods for each attribute and reference. Sample instance interface 345 also includes operation methods for each operation. The instance interface name is the same as the class name.
Hard-coding JMI interface implementations requires significant coding efforts, both initially and subsequently due to JMI Specification changes. What is needed is a solution that decreases the amount of hard-coding required to implement a JMI interface.